Skip to content

Topic/adding function read device identification#474

Open
purewasa wants to merge 2 commits intostephane:masterfrom
purewasa:topic/adding-function-read-device-identification
Open

Topic/adding function read device identification#474
purewasa wants to merge 2 commits intostephane:masterfrom
purewasa:topic/adding-function-read-device-identification

Conversation

@purewasa
Copy link
Copy Markdown

Bonjour et hello!

Over four years ago I send you a patch for libmodbus, that implements the Modbus protocol function READ DEVICE IDENTIFICATION. As an answer, you requested a more DRY Version (see libmodbus mailing list https://groups.google.com/forum/#!msg/libmodbus/eH1NcZ7YVdk/PXFJlvf26PwJ ).
Unfortunately, at that time, it was not possible for me to rework the patch.
Meanwhile, there is a greater need in my department to mainline the changes, we made to open source projects, that we use in our devices. Because of that, the focus has come back to libmodbus.

So, here is my more DRY and improved version of the patch from those days.
It is based on the HEAD of the current master branch of libmodbus from your github account
It consists of two commits:

  • one adding the function modbus_read_device_identification(), and
  • one providing a test tool.

The function has been used in our embedded devices with the non-DRY version for three
years, now. There never seemed to be a problem, as far as I know.
But it only has been used for serial Modbus RTU.

Even the new patch has only been tested with Modbus RTU, using Linux. It should be able to handle
Modbus TCP correctly, as well, thanks to the improvements I made.

Modbus devices that implements the Modbus protocol specification correctly, but don't
support the READ DEVICE IDENTIFICATION function send an "illegal function" exception.
This case has been tested with one Modbus device.

This patch implements the function modbus_read_device_identification
which realizes the function code 0x2B / 0x0E READ DEVICE
IDENTIFICATION of the official MODBUS Protocol Specification
(http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf)
Chapter 6.21.
printf("read_device_id returned: %d\n", rc);
more_follows = response[4];
next_object_id = response[5];
int object_cnt = response[6];
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the fact that all of this stuff still has to managed by the client makes me feel like this API isn't really ready for mainstream inclusion in the library. I feel MEI stuff needs a much more extensible API layer than just what you've done here, to have a chance of letting people use MEI other than just this subcode. Even for this subcode, you're requiring a lot of machinery on the library client, and imposing a lot of knowledge of the byte arrangement of the replies, all of which libmodbus is meant to be abstracting for you.

@purewasa
Copy link
Copy Markdown
Author

Dear karlp,

thank you for your reply.

As far as I can see all this MEI stuff is very much controller dependent and therefore not easy to abstract. The only thing that comes to my mind is:
The library could abstract giving back the fields of the result as a linked list.
Expressed in C++11 (just for clarification), the return type could be list<array>.
But this is just a vague idea.

Unfortunately, I don't have the resources available at the moment to work on that.

Kind regards

purewasa

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants